It is often times necessary and well known in the art to perform rollback operations. This is typically used when data has been corrupted, and it is desired to revert to an earlier form of the data that is uncorrupted. For instance, if a database were corrupted it would be desirable to roll back to an earlier uncorrupted version, and then update that version to bring it up-to date. It is well known to accomplish this rollback task by using snapshots of changes made to the data during a session. Sessions may be run daily and a snapshot (a point-in-time copy of the data) taken once a day, such that in the event a rollback is necessary, only a single day worth of changes have been lost. For example, if a snapshot is taken every night, and on Friday afternoon it is discovered that the database is corrupted, the database can be rolled back to the Thursday night data by way of the snapshot taken Thursday night. Steps can then be taken to update that copy. In such a manner only a single days worth of database updates are lost or may need to be reapplied.
One problem with performing rollbacks is that all snapshots which were taken after the snapshot which is rolled back to become unusable. Thus, if on a Friday it was discovered that the database is corrupted and needs to be rolled back to the Tuesday copy, the snapshots taken Wednesday and Thursday would be lost after the rollback to the Tuesday snapshot was performed. This is due to the mapping mechanism used to map changes to the data while creating the snapshot. Should it be later determined that a rollback to Wednesday copy would have been sufficient, that rollback cannot be accomplished since the Wednesday snapshot has been rendered unusable by the rollback to an earlier snapshot.
In view of the foregoing it would be desirable to provide a method of performing rollbacks that does not result in the destruction of later snapshots of the data.